You can read this chapter thoroughly to gain an in-depth understanding of how information is routed across the Internet or you can use this chapter as an extended glossary, referring to it only when encountering unfamiliar terms later in this book.
The chapter begins with fundamental concepts and closes with a comprehensive look at TCP/IP. The chapter is broken into three parts. The first part answers some basic questions you might have, including
The final portion of this chapter explores key TCP/IP utilities with which each user must become familiar. These utilities are of value in maintenance and monitoring of any TCP/IP network.
Note that this chapter is not an exhaustive treatment of TCP/IP. It provides only the minimum knowledge needed to continue reading this book. Throughout this chapter, however, I supply links to documents and other resources from which the reader can gain an in-depth knowledge of TCP/IP.
Protocols within the TCP/IP suite work together to provide data transport on the Internet. In other words, these protocols provide nearly all services available to today's Net surfer. Some of those services include
For the moment, this explanation will suffice: TCP/IP refers to a collection of protocols that facilitate communication between machines over the Internet (or other networks running TCP/IP).
The prototype for this system emerged quickly, based in part on research done in 1962 and 1963. That prototype was called ARPANET. ARPANET reportedly worked well, but was subject to periodic system crashes. Furthermore, long-term expansion of that network proved costly. A search was initiated for a more reliable set of protocols; that search ended in the mid-1970s with the development of TCP/IP.
TCP/IP had significant advantages over other protocols. For example, TCP/IP was lightweight (it required meager network resources). Moreover, TCP/IP could be implemented at much lower cost than the other choices then available. Based on these amenities, TCP/IP became exceedingly popular. In 1983, TCP/IP was integrated into release 4.2 of Berkeley Software Distribution (BSD) UNIX. Its integration into commercial forms of UNIX soon followed, and TCP/IP was established as the Internet standard. It has remained so (as of this writing).
As more users flock to the Internet, however, TCP/IP is being reexamined. More users translates to greater network load. To ease that network load and offer greater speeds of data transport, some researchers have suggested implementing TCP/IP via satellite transmission. Unfortunately, such research has thus far produced dismal results. TCP/IP is apparently unsuitable for this implementation.
Today, TCP/IP is used for many purposes, not just the Internet. For example, intranets are often built using TCP/IP. In such environments, TCP/IP can offer significant advantages over other networking protocols. One such advantage is that TCP/IP works on a wide variety of hardware and operating systems. Thus, one can quickly and easily create a heterogeneous network using TCP/IP. Such a network might have Macs, IBM compatibles, Sun Sparcstations, MIPS machines, and so on. Each of these can communicate with its peers using a common protocol suite. For this reason, since it was first introduced in the 1970s, TCP/IP has remained extremely popular. In the next section, I will discuss implementation of TCP/IP on various platforms.
| Platform | TCP/IP Support |
| UNIX | Native |
| DOS | Piper/IP By Ipswitch |
| Windows | TCPMAN by Trumpet Software |
| Windows 95 | Native |
| Windows NT | Native |
| Macintosh | MacTCP or OpenTransport (Sys 7.5+) |
| OS/2 | Native |
| AS/400 OS/400 | Native |
Platforms that do not natively support TCP/IP can still implement it through the use of proprietary or third-party TCP/IP programs. In these instances, third-party products can offer varied functionality. Some offer very good support and others offer marginal support.
For example, some third-party products provide the user with only basic TCP/IP. For most users, this is sufficient. (They simply want to connect to the Net, get their mail, and enjoy easy networking.) In contrast, certain third-party TCP/IP implementations are comprehensive. These may allow manipulation of compression, methods of transport, and other features common to the typical UNIX TCP/IP implementation.
Widespread third-party support for TCP/IP has been around for only a few years. Several years ago, for example, TCP/IP support for DOS boxes was very slim.
One interesting point about non-native, third-party TCP/IP implementations is this: Most of them do not provide servers within their distributions. Thus, although a user can connect to remote machines to transfer a file, the user's machine cannot accept such a request. For example, a Windows 3.11 user using TCPMAN cannot--without installing additional software--accept a file-transfer request from a remote machine. Later in this chapter you'll find a list of a few names of such additional software for those who are interested in providing services via TCP/IP.
TIP: There is actually a wonderful product called Minuet that can be used in conjunction with a packet driver on LANs. Minuet derived its name from the term Minnesota Internet Users Essential Tool. Minuet offers quick and efficient access to the Net through a DOS-based environment. This product is still available free of charge at many locations, including ftp://minuet.micro.umn.edu/pub/minuet/.
Figure 6.1.
The TCP/IP stack.
After data has passed through the process illustrated in Figure 6.1, it travels to its destination on another machine or network. There, the process is executed in reverse (the data first meets the physical layer and subsequently travels its way up the stack). Throughout this process, a complex system of error checking is employed both on the originating and destination machine.
Each layer of the stack can send data to and receive data from its adjoining layer. Each layer is also associated with multiple protocols. At each tier of the stack, these protocols are hard at work, providing the user with various services. The next section of this chapter examines these services and the manner in which they are associated with layers in the stack. You will also examine their functions, the services they provide, and their relationship to security.
Important network-level protocols include
TIP: Sniffers are devices that can monitor such processes. A sniffer is a device--either hardware or software--that can read every packet sent across a network. Sniffers are commonly used to isolate network problems that, while invisible to the user, are degrading network performance. As such, sniffers can read all activity occurring between network-level protocols. Moreover, as you might guess, sniffers can pose a tremendous security threat. You will examine sniffers in Chapter 12, "Sniffers."
Cross Reference: For more comprehensive information about protocols (or the stack in general), I highly recommend Teach Yourself TCP/IP in 14 Days by Timothy Parker, Ph.D (Sams Publishing).
An ARP request message is broadcast on the subnet. This request is received by a router that replies with the requested hardware address. This reply is caught by the originating machine and the transfer process can begin.
ARP's design includes a cache. To understand the ARP cache concept, consider this: Most modern HTML browsers (such as Netscape Navigator or Microsoft's Internet Explorer) utilize a cache. This cache is a portion of the disk (or memory) in which elements from often-visited Web pages are stored (such as buttons, headers, and common graphics). This is logical because when you return to those pages, these tidbits don't have to be reloaded from the remote machine. They will load much more quickly if they are in your local cache.
Similarly, ARP implementations include a cache. In this manner, hardware addresses of remote machines or networks are remembered, and this memory obviates the need to conduct subsequent ARP queries on them. This saves time and network resources.
Can you guess what type of security risks might be involved in maintaining such an ARP cache? At this stage, it is not particularly important. However, address caching (not only in ARP but in all instances) does indeed pose a unique security risk. If such address-location entries are stored, it makes it easier for a cracker to forge a connection from a remote machine, claiming to hail from one of the cached addresses.
Cross Reference: Readers seeking in-depth information on ARP should see RFC 826 (http://www.freesoft.org/Connected/RFC/826).
Cross Reference: Another good reference for information on ARP is Margaret K. Johnson's piece about details of TCP/IP (excerpts from Microsoft LAN Manager TCP/IP Protocol) (http://www.alexia.net.au/~www/yendor/internetinfo/index.html).
TIP: Perhaps the most widely known ICMP implementation involves a network utility called ping. Ping is often used to determine whether a remote machine is alive. Ping's method of operation is simple: When the user pings a remote machine, packets are forwarded from the user's machine to the remote host. These packets are then echoed back to the user's machine. If no echoed packets are received at the user's end, the ping program usually generates an error message indicating that the remote host is down.
Cross Reference: I urge those readers seeking in-depth information about ICMP to examine RFC 792 (http://sunsite.auc.dk/RFC/rfc/rfc792.html).
Figure 6.2.
The IP datagram.
As illustrated, an IP datagram is composed of several parts. The first part, the header, is composed of miscellaneous information, including originating and destination IP address. Together, these elements form a complete header. The remaining portion of a datagram contains whatever data is then being sent.
The amazing thing about IP is this: If IP datagrams encounter networks that require smaller packages, the datagrams bust apart to accommodate the recipient network. Thus, these datagrams can fragment during a journey and later be reassembled properly (even if they do not arrive in the same sequence in which they were sent) at their destination.
Even further information is contained within an IP datagram. Some of that information may include identification of the protocol being used, a header checksum, and a time-to-live specification. This specification is a numeric value. While the datagram is traveling the void, this numeric value is constantly being decremented. When that value finally reaches a zero state, the datagram dies. Many types of packets have time-to-live limitations. Some network utilities (such as Traceroute) utilize the time-to-live field as a marker in diagnostic routines.
In closing, IP's function can be reduced to this: providing packet delivery over the Internet. As you can see, that packet delivery is complex in its implementation.
Cross Reference: I refer readers seeking in-depth information on Internet protocol to RFC 760 (http://sunsite.auc.dk/RFC/rfc/rfc760.html).
The TCP system relies on a virtual circuit that is established between the requesting machine and its target. This circuit is opened via a three-part process, often referred to as the three-part handshake. The process typically follows the pattern illustrated in Figure 6.3.
Figure 6.3.
The TCP/IP three-way handshake.
After the circuit is open, data can simultaneously travel in both directions. This results in what is sometimes called a full-duplex transmission path. Full-duplex transmission allows data to travel to both machines at the same time. In this way, while a file transfer (or other remote session) is underway, any errors that arise can be forwarded to the requesting machine.
TCP also provides extensive error-checking capabilities. For each block of data sent, a numeric value is generated. The two machines identify each transferred block using this numeric value. For each block successfully transferred, the receiving host sends a message to the sender that the transfer was clean. Conversely, if the transfer is unsuccessful, two things may occur:
Similarly, if no confirmation is received within a specified time period, the information is also retransmitted. This process is repeated as many times as necessary to complete the transfer or remote session.
You have examined how the data is transported when a connect request is made. It is now time to examine what happens when that request reaches its destination. Each time one machine requests a connection to another, it specifies a particular destination. In the general sense, this destination is expressed as the Internet (IP) address and the hardware address of the target machine. However, even more detailed than this, the requesting machine specifies the application it is trying to reach at the destination. This involves two elements:
Daemons are programs that continuously listen for other processes (in this case, the process listened for is a connection request). Daemons loosely resemble terminate and stay resident (TSR) programs in the Microsoft platform. These programs remain alive at all times, constantly listening for a particular event. When that event finally occurs, the TSR undertakes some action.
inetd is a very special daemon. It has been called many things, including the super-server or granddaddy of all processes. This is because inetd is the main daemon running on a UNIX machine. It is also an ingenious tool.
Common sense tells you that running a dozen or more daemon processes could eat up machine resources. So rather than do that, why not create one daemon that could listen for all the others? That is what inetd does. It listens for connection requests from the void. When it receives such a request, it evaluates it. This evaluation seeks to determine one thing only: What service does the requesting machine want? For example, does it want FTP? If so, inetd starts the FTP server process. The FTP server can then process the request from the void. At that point, a file transfer can begin. This all happens within the space of a second or so.
In general, inetd is started at boot time and remains resident (in a listening state) until the machine is turned off or until the root operator expressly terminates that process.
TIP: inetd isn't just for UNIX anymore. For example, Hummingbird Communications has developed (as part of its Exceed 5 product line) a version of inetd for use on any platform that runs Microsoft Windows or OS/2. There are also non- commercial versions of inetd, written by students and other software enthusiasts. One such distribution is available from TFS software and can be found at http://www.trumpton.demon.co.uk/software/inetd.html.
The behavior of inetd is generally controlled from a file called inetd.conf, located in the /etc directory on most UNIX platforms. The inetd.conf file is used to specify what services will be called by inetd. Such services might include FTP, Telnet, SMTP, TFTP, Finger, Systat, Netstat, or any other processes that you specify.
To facilitate this process, each application (FTP or Telnet, for example) is assigned a unique address. This address is called a port. The application in question is bound to that particular port and, when any connection request is made to that port, the corresponding application is launched (inetd is the program that launches it).
There are thousands of ports on the average Internet server. For purposes of convenience and efficiency, a standard framework has been developed for port assignment. (In other words, although a system administrator can bind services to the ports of his or her choice, services are generally bound to recognized ports. These are commonly referred to as well-known ports.)
Please peruse Table 6.2 for some commonly recognized ports and the applications typically bound to them.
| Service or Application | Port |
| File Transfer Protocol (FTP) | 21 |
| Telnet | 23 |
| Simple Mail Transfer Protocol (SMTP) | 25 |
| Gopher | 70 |
| Finger | 79 |
| Hypertext Transfer Protocol (HTTP) | 80 |
| Network News Transfer Protocol (NNTP) | 119 |
I will examine each of the applications described in Table 6.2. All are application-level protocols or services (that is, they are visible to user and the user can interact with them at the console).
Cross Reference: For a comprehensive list of all port assignments, visit ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers. This document is extremely informative and exhaustive in its treatment of commonly assigned port numbers.
For those of you who are unfamiliar with Telnet, it operates much like the interface of a bulletin board system (BBS). Telnet is an excellent application for providing a terminal-based front end to databases. For example, better than 80 percent of all university library catalogs can be accessed via Telnet. Figure 6.4 shows an example of a Telnet library catalog screen.
Figure 6.4.
A sample Telnet session.
Even though GUI applications have taken the world by storm, Telnet--which is essentially a text-based application--is still incredibly popular. There are many reasons for this. First, Telnet allows you to perform a variety of functions (retrieving mail, for example) at a minimal cost in network resources. Second, implementing secure Telnet is a pretty simple task. There are several programs to implement this, the most popular of which is Secure Shell (which I will explore later in this book).
To use Telnet, the user issues whatever command necessary to start his or her Telnet client, followed the name (or numeric IP address) of the target host. In UNIX, this is done as follows:
#telnet internic.netThis command launches a Telnet session, contacts internic.net, and requests a connection. That connection will either be honored or denied, depending on the configuration at the target host. In UNIX, the Telnet command has long been a native one. That is, Telnet has been included with basic UNIX distributions for well over a decade. However, not all operating systems have a native Telnet client. Table 6.3 shows Telnet clients for various operating systems.
| Operating System | Client |
| UNIX | Native |
| Microsoft Windows 95 | Native (command line), ZOC, NetTerm, Zmud, WinTel32, Yawtelnet |
| Microsoft Windows NT | Native (command line), CRT, and all listed for 95 |
| Microsoft Windows 3.x | Trumptel Telnet, Wintel, Ewan |
| Macintosh | NCSA Telnet, NiftyTelnet, Comet |
| VAX | Native |
Cross Reference: RFC 114 contains the first definition of FTP, but a more practical document might be RFC 959 (http://www.freesoft.org/Connected/RFC/959/index.html).
| Operating System | Client |
| UNIX | Native, LLNLXDIR2.0, FTPtool |
| Microsoft Windows 95 | Native, WS_FTP, Netload, Cute-FTP, Leap FTP, SDFTP, FTP Explorer |
| Microsoft Windows NT | See listings for Windows 95 |
| Microsoft Windows 3.x | Win_FTP, WS_FTP, CU-FTP, WSArchie |
| Macintosh | Anarchie, Fetch, Freetp |
| OS/2 | Gibbon FTP, FTP-IT, Lynn's Workplace FTP |
| VAX | Native |
FTPD FTPD is the standard FTP server daemon. Its function is simple: to reply to connect requests received by inetd and to satisfy those requests for file transfers. This daemon comes standard on most distributions of UNIX (for other operating systems, see Table 6.5).
| Operating System | Client |
| UNIX | Native (FTPD) |
| Microsoft Windows 95 | WFTPD, Microsoft FrontPage, WAR FTP Daemon, Vermilion |
| Microsoft Windows NT | Serv-U, OmniFSPD, Microsoft Internet Information Server |
| Microsoft Windows 3.x | WinQVT, Serv-U, Beames & Whitside BW Connect, WFTPD FTP Server, WinHTTPD |
| Macintosh | Netpresenz, FTPD |
| OS/2 | Penguin |
FTPD waits for a connection request. When such a request is received, FTPD requests the user login. The user must either provide his or her valid user login and password or may log in anonymously.
Once logged in, the user may download files. In certain instances and if security on the server allows, the user may also upload files.
Despite the simple character of SMTP, mail service has been the source of countless security holes. (This may be due in part to the number of options involved. Misconfiguration is a common reason for holes.) I will discuss these security issues later in this book.
SMTP servers are native in UNIX. Most other networked operating systems now have some form of SMTP, so I'll refrain from listing them here.
Cross Reference: Further information on this protocol is available in RFC 821 (http://sunsite.auc.dk/RFC/rfc/rfc821.html).
The Gopher service is very powerful. It can serve text documents, sounds, and other media. It also operates largely in text mode and is therefore much faster than HTTP through a browser. Undoubtedly, the most popular Gopher client is for UNIX. (Gopher2_3 is especially popular, followed by Xgopher.) However, many operating systems have Gopher clients. See Table 6.6 for a few.
Cross Reference: The complete documentation on the Gopher protocol can be obtained in RFC 1436 (http://sunsite.auc.dk/RFC/rfc/rfc1436.html).
| Operating System | Client |
| Microsoft Windows (all) | Hgopher, Ws_Gopher |
| Macintosh | Mac Turbo Gopher |
| AS/400 | The AS/400 Gopher Client |
| OS/2 | Os2Gofer |
Typically, the user launches a Gopher client and contacts a given Gopher server. In turn, the Gopher server forwards a menu of choices. These may include search menus, pre-set destinations, or file directories. Figure 6.5 shows a client connection to the University of Illinois.
Figure 6.5.
A sample gopher session.
Note that the Gopher model is completely client/server based. The user never logs on per se. Rather, the client sends a message to the Gopher server, requesting all documents (or objects) currently available. The Gopher server responds with this information and does nothing else until the user requests an object.
HTTP has forever changed the nature of the Internet, primarily by bringing the Internet to the masses. In some ways, its operation is much like Gopher. For example, it too works via a request/response scenario. And this is an important point. Whereas applications such as Telnet require that a user remain logged on (and while they are logged on, they consume system resources), protocols such as Gopher and HTTP eliminate this phenomenon. Thus, the user is pushed back a few paces. The user (client) only consumes system resources for the instant that he or she is either requesting or receiving data.
NOTE: RFC 1945 has been superseded by RFC 2068, which is a more recent specification of HTTP and is available at ftp://ds.internic.net/rfc/rfc2068.txt.
Using a common browser like Netscape Navigator or Microsoft Internet Explorer, you can monitor this process as it occurs. For each data element (text, graphic, sound) on a WWW page, your browser will contact the server one time. Thus, it will first grab text, then a graphic, then a sound file, and so on. In the lower-left corner of your browser's screen is a status bar. Watch it for a few moments when it is loading a page. You will see this request/response activity occur, often at a very high speed.
HTTP doesn't particularly care what type of data is requested. Various forms of multimedia can be either embedded within or served remotely via HTML-based WWW pages. In short, HTTP is an extremely lightweight and effective protocol. Clients for this protocol are enumerated in Table 6.7.
| Operating System | HTTP Client |
| Microsoft Windows (all) | Netscape Navigator, WinWeb, Mosaic, Microsoft Internet Explorer, WebSurfer, NetCruiser, AOL, Prodigy |
| Macintosh | Netscape Navigator, MacMosaic, MacWeb, Samba, Microsoft Internet Explorer |
| UNIX | Xmosaic, Netscape Navigator, Grail, Lynx, TkWWW, Arena |
| OS/2 | Web Explorer, Netscape Navigator |
Until recently, UNIX alone supported an HTTP server. (The standard was NCSA HTTPD. Apache has now entered the race, giving HTTPD strong competition in the market.) The application is extremely small and compact. Like most of its counterparts, it runs as a daemon. Its typically assigned port is 80. Today, there are HTTP servers for nearly every operating system. Table 6.8 lists those servers.
| Operating System | HTTP Server |
| Microsoft Windows 3.x | Website, WinHTTPD |
| Microsoft Windows 95 | OmniHTTPD, Server 7, Nutwebcam, Microsoft Personal Web Server, Fnord, ZB Server, Website, Folkweb |
| Microsoft Windows NT | HTTPS, Internet Information Server, Alibaba, Espanade, Expresso, Fnord, Folkweb, Netpublisher, Weber, OmniHTTPD, WebQuest, Website, Wildcat |
| Macintosh | MacHTTP, Webstar, Phantom, Domino, Netpresenz |
| UNIX | HTTPD, Apache |
| OS/2 | GoServe, OS2HTTPD, OS2WWW, IBM Internet Connection Server, Bearsoft, Squid & Planetwood |
Cross Reference: I refer readers seeking in-depth information on NNTP to RFC 977 (http://andrew2.andrew.cmu.edu/rfc/rfc977.html).
You may also wish to obtain RFC 850 for examination of earlier implementations of the standard (http://sunsite.auc.dk/RFC/rfc/rfc850.html).
In essence, the point I would like to make is this: The Internet was designed as a system with multiple avenues of communication. Each protocol is one such avenue. As such, there are hundreds of ways to move data across the Net.
Until recently, utilizing these protocols called for accessing them one at a time. That is, to arrest a Gopher session and start a Telnet session, the user had to physically terminate the Gopher connection.
The HTTP browser changed all that and granted the average user much greater power and functionality. Indeed, FTP, Telnet, NTTP, and HTTP are all available at the click of a button.
© Copyright, Macmillan Computer Publishing. All rights reserved.